---
title: Production Deployment
description: Deploying and managing a self-hosted Latitude instance for production use.
---

## Infrastructure Components

A typical production deployment involves several key services:

1. **Web Application**: The main Next.js frontend (e.g., `app` service).
2. **API Gateway**: Handles incoming API requests (e.g., `gateway` service).
3. **Workers**: Processes background jobs like evaluations and dataset generation (e.g., `worker` service).
4. **WebSockets**: Manages real-time connections (e.g., `websockets` service).
5. **Database**: PostgreSQL for storing persistent data.
6. **Cache/Queue**: Redis for caching and message queuing.
7. **Reverse Proxy/Load Balancer**: (e.g., Traefik, Nginx, Caddy, Cloud Load Balancer) Handles incoming traffic, SSL termination, and routing to services.
8. **Object Storage (Recommended)**: S3-compatible storage for files like uploaded datasets or images.

## Installation Methods

While Latitude can be run using `docker compose` on a single machine, production deployments often benefit from more robust methods:

### 1. Docker Compose (Single Server)

- **Pros**: Simple setup for smaller deployments or initial testing.
- **Cons**: Limited scalability and fault tolerance.
- **Setup**: Follow the Docker Compose instructions, ensuring production-ready configuration in your `.env` file (strong passwords, S3 storage, proper domain/SSL setup via Traefik or another proxy).

  ```bash
  # Ensure .env is configured for production
  cp .env.example .env
  # Edit .env with production values (DB creds, S3, Traefik email, domain, etc.)
  docker network create web # If using Traefik default config
  docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d
  ```

<Tip>
  We only provide amd64 images, if you are using Mac OS with Apple Sillicon, you
  will need to enable amd64 emulation and download the amd64 images.
</Tip>

### 2. Container Orchestration (Kubernetes, ECS, etc.)

- **Pros**: Scalability, high availability, automated management.
- **Cons**: More complex initial setup.
- **Setup**: Requires creating deployment manifests (e.g., Kubernetes YAML, ECS Task Definitions) for each Latitude service (web, gateway, worker, websockets). You'll need to manage database and Redis instances separately (e.g., using managed cloud services like RDS/ElastiCache or deploying them within the orchestrator).
  - Configure ingress controllers (like Nginx Ingress or Traefik Ingress) for routing.
  - Manage secrets securely (e.g., Kubernetes Secrets, AWS Secrets Manager).
  - Set up persistent volumes for the database.

### 3. Platform-as-a-Service (PaaS)

- Services like Heroku, Render, or Fly.io might be suitable, often requiring Docker container deployments.
- You'll need to configure buildpacks or Dockerfiles and manage addons for databases and Redis.

### 4. Helm Chart (OCI)

The chart is automatically published to GitHub Container Registry by the workflow
`.github/workflows/publish-helm-chart.yml` on tags matching `helm-chart-v*`. Install it with:

```bash
helm install latitude oci://ghcr.io/<owner>/latitude \
  --version <version> \
  -n latitude --create-namespace \
  -f charts/latitude/values.yaml \
  -f charts/latitude/values.secrets.yaml
```

## Configuration for Production

Regardless of the method, ensure these are configured correctly:

- **`.env` File**: Set strong `POSTGRES_PASSWORD`, configure `APP_DOMAIN` and `APP_URL`, set up `MAIL_TRANSPORT` (e.g., SMTP, Mailgun) with valid credentials, configure `DRIVE_DISK` (recommend `s3`).
- **Storage**: Use S3-compatible object storage (`DRIVE_DISK=s3`) for scalability and persistence. Configure bucket names and IAM roles or access keys securely.
- **Database & Redis**: Use managed services (RDS, ElastiCache, Memorystore) or ensure your self-hosted instances are properly configured for performance, backups, and security.
- **Latitude Analytics**: We collect [anonymous usage data](https://github.com/latitude-dev/latitude-llm/blob/main/packages/core/src/lib/analytics/collectors/OpenSource.ts) to improve the product. You can opt-out by setting `OPT_OUT_ANALYTICS=true` in your `.env` file.
- **Reverse Proxy/SSL**: Configure your reverse proxy (Traefik, Nginx, etc.) to handle SSL termination (e.g., using Let's Encrypt) and route traffic correctly to the Latitude services.
- **Resource Allocation**: Ensure sufficient CPU, memory, and disk space for each service, especially the database and workers.

## Connecting Provider API Keys

In a self-hosted setup, Latitude needs access to your AI provider API keys (OpenAI, Anthropic, etc.) to function.

- **Configuration Method**: Add these keys securely to the environment where the Latitude services (specifically the gateway and potentially workers/API) run.
  - **Docker Compose**: Add them to your `.env` file (e.g., `OPENAI_API_KEY=sk-...`).
  - **Kubernetes**: Store them as Kubernetes Secrets and mount them as environment variables in your deployments.
  - **ECS**: Use AWS Secrets Manager or Parameter Store integrated with Task Definitions.
- **Latitude UI**: Once configured in the environment, you might still need to "register" the provider within the Latitude Admin UI (Settings > Providers), but you typically won't need to paste the key directly into the UI if it's available in the environment.

## Scaling and Updating

- **Scaling**: With orchestrators, you can scale services horizontally by increasing replica counts (especially for `web`, `gateway`, `worker`, `websockets`). Scale database and Redis resources vertically or use managed services that scale.
- **Updating**: Pull the latest official Docker images from the [Latitude GitHub Container Registry](https://github.com/orgs/latitude-dev/packages) (or build your own from the latest source) and update your deployments (e.g., `docker compose pull && docker compose up -d`, `kubectl rollout restart deployment`, update ECS service).
- **Migrations**: Ensure database migrations run automatically on startup (the default `docker-compose.yml` includes a migrations service) or run them manually before updating application services (`cd packages/core && pnpm db:migrate`).

## Security and Backups

- **Security**: Restrict access to database and Redis ports, use strong passwords, keep dependencies updated, configure firewall rules, secure API keys and secrets.
- **Backups**: Implement regular backups for your PostgreSQL database. If using local storage (`DRIVE_DISK=local`), ensure the storage volume is backed up.

## Self-Hosting MCP Integrations

If using [Third-Party Integrations via MCP](/guides/integration/mcp-integrations), you'll need to deploy and manage those MCP servers within your infrastructure as well.

## Monitoring and Logging

- **Logging**: Configure Docker log drivers or orchestrator logging to aggregate logs from all services (web, gateway, worker, etc.).
- **Monitoring**: Use tools like Prometheus/Grafana, Datadog, or cloud provider monitoring services to track resource usage (CPU, memory), error rates, request latency, and queue lengths.
- **Health Checks**: Configure health check endpoints in your load balancer or orchestrator to monitor service availability.
- **Optional Integrations**: Configure Sentry (`SENTRY_DSN`) or PostHog in your `.env` for enhanced error tracking and analytics.

## Next Steps

- Review the [Local Development Setup](/guides/self-hosted/development-setup)
- Consult specific documentation for your chosen orchestrator or PaaS.
